In networks, data is typically exchanged between communicating devices in the form of “frames.” Frames include a source MAC address and a destination MAC address. A MAC address uniquely identifies a network device in a “Layer 2” communication protocol used in Ethernet and Token Ring LANs. A routing device (i.e., switch, bridge, or the like) connected between communicating devices uses the destination MAC address in an incoming frame generated by a source device and forwards the frame to the appropriate destination device.
Flow control of such frame-based data in a network using Ethernet protocol is achieved by either dropping packets or with a congestion avoidance mechanism such as back-pressure or pause. Either of these mechanisms is executed in a hop-by-hop method. A node in the network experiencing the congestion condition reacts in a manner such that a node that is upstream of the congested node receives a back-pressure or pause message that stops all transmission towards such congested node. Unfortunately, this type of messaging can propagate further in the network. That is, a distinction cannot be made among the different data flows between various nodes as to which flow is the cause of the congestion. Additionally, the back-pressure method may also propagate in such a way as to throttle traffic which might not be passing the congested node. Accordingly, Ethernet is inherently incapable of differentiating between problematic and acceptable traffic flows or streams in a network. In other words, Ethernet has no selective flow mechanism or capabilities.
This condition is further aggravated when Ethernet bridges are used to connect nodes (via pathways) because Ethernet bridges learn every MAC address that is passing therethrough. The Ethernet bridge is not capable of determining whether such MAC address resides one hop away or several hops away in another portion of the network either of which may or may not be contributing to part of the congestion pathways.